前言

其實簡單來說，就如名稱一樣，Row-based Database 就是以列為單位儲存， Columnar Database 就是以行為單位儲存。

看圖最快：

Row-based Database

Row-based 資料庫是傳統的資料庫結構設計，數據按照列的順序儲存在硬碟上，每一列代表一條完整的記錄。這種方式適合處理事務型操作，如新增、修改、刪除，並且非常適合OLTP系統高效地查詢整列數據。

應用場景：適用於頻繁的資料列讀寫操作，比如客戶訂單、財務交易記錄等。

優勢：

• 快速處理單條或多條記錄的增刪改查操作。
• 在事務處理中高效，特別是在需要頻繁的新增、修改和刪除的情境。
• 常見的資料庫：MySQL、PostgreSQL、Oracle 等關聯式資料庫。

Columnar Database

Columnar 資料庫將數據按行、區塊儲存，而不是按列存儲。這種儲存方式在進行數據分析時特別有效，尤其是當只需要查詢部分欄位的情況下，因為可以只讀取需要的行而非整列數據。這使其非常適合OLAP系統。

應用場景：適用於需要對大規模數據進行快速查詢和分析的情境，如數據倉庫和商業智能（BI）應用。

優勢：

• 大規模、指定欄位、進行彙總操作（如 SUM、AVG、COUNT）的查詢效率高，
• 更好的數據壓縮，因為同一行的數據類型相同，易於使用壓縮算法。
• 常見的資料庫：Amazon Redshift、Google BigQuery。

查詢的差異與效能小技巧

Row-based Database

通常會透過 key 的方式儲存，並且透過額外的樹狀結構 B+ Tree 來儲存key，因此你必須盡可能使用到index key，舉例來說，10萬筆資料，如果從第一筆資料開始查，最差的情況要查詢 10萬次 O(N) 才能查到，轉換成 B+ Tree 以後，可以縮短為約5次 O(logN) 就查詢完成，如果你是資訊相關科系的學生，應該就對這些不陌生，大一會寫很多排序演算法，這些研究都在幫助資料的查詢速度能更有效率。

SQL 效能重點:

• 必須用到 index，以使用樹狀結構查詢，避免線性查詢
• 因為正規化設計，需要透過多次 JOIN 取得相關的資訊
• 盡可能限制查詢筆數，但 WHERE 要注意使用到有index 的欄位做條件限制，最差也可以用 limit 100

Columnar Database

由於 Columnar 資料庫的儲存是以欄位(行) 為單位，在 Google BigQuery 的設計甚至可以加上以『天』為單位去做切塊，所以在查詢的優化會以盡可能減少選擇的欄位、加上時間區塊限制，來加速查詢。

SQL 效能重點:

• 避免 SELECT *，只挑選必要欄位
• 若工具允許，加上時間的 Chunk，例如: BigQuery 的 time partition
• WHERE 加上時間區段限制，避免查詢整個資料表

小結

這篇想幫助大家開始能了解資料庫底層結構的邏輯和設計，row-based 與 columnar database 比較起來，row-based 資料庫的歷史比較悠久，主要透過前期的資料表設計來提升效率、查詢也會比較複雜，columnar 資料庫就相對直覺，主推把所有資料都先存起來，讓資料需求者可以先當個快樂的使用者，只要小心不要讓查詢成本爆預算就好。

身為一個資料工程師，如果能了解更多一些關聯式資料庫的設計邏輯，能夠幫助你對於資料效能有更深一層的認識，因此下一篇文章會針對 MySQL 關聯式資料庫 做更深入的介紹。